Web based real time communication services (WebRTC) have become more popular in recent years. A majority of WebRTC clients are web browsers and used behind a Network Address Translation (NAT) and/or firewall. WebRTC clients uses a Real-time Transport Protocol (RTP)/User Datagram Protocol (UDP) based data transmission scheme for multimedia sessions. UDP has well known NAT traversal problems and without native capabilities to traverse a NAT, WebRTC clients will be limited in their functionality. Fortunately, NAT traversal for UDP is a solved problem, but solutions require that clients transmitting media between each other use the same NAT traversal algorithms. Without a consistent, well specified NAT traversal mechanism, WebRTC client implementations would likely be inoperable with each other.
For Hypertext Transfer Protocol (HTTP)/Transmission Control Protocol (TCP), the NAT traversal over port 80 is standard and solves the problem of NAT traversal. But TCP is not designed for real-time communications due to the TCP behaviour and its transaction control mechanisms using retransmission and acknowledgement procedures. Thus, the TCP architecture gives long delays and poor Quality of experience (QoE) for real-time applications.
The classical Internet Protocol (IP) protocol stack architecture in a communication terminal is shown in FIG. 1, with the application codec (not shown) located above the HTTP/application layer. Other examples of protocols in the application layer includes Domain Name System (DNS), File Transfer Protocol (FTP) and RTP. Below the application layer resides the transport layer with the TCP and UDP protocols. The task of TCP is to transmit IP packets in a reliable way from point A to B. But in the case of low delay and real time there is no time for retransmission, i.e., even if the IP packet is re-sent, it will be received too late and discarded by the receiving side (e.g., transcoder). UDP is typically used where retransmission is not used and the application is designed to handle some level of packet loss without major impact on the perceived quality of the service. Below the transport protocol is the IP layer, and lower still is the link layer with the Ethernet protocol, etc.
As shown in FIG. 2, a TCP session between a source/client device and a destination/server device comprises signalling in three phases, a connection setup phase, a data transfer phase where the actual data is transferred between the devices with acknowledgements sent in-between, and a connection teardown phase.